Date: Tue, 14 Jun 94 04:30:13 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #194 To: Ham-Digital Ham-Digital Digest Tue, 14 Jun 94 Volume 94 : Issue 194 Today's Topics: An open note to Gary Coffman, KE4ZV (6 msgs) Need info on Ottawa PI Card Packet Ideas Sought... Thenet Eprom 1X for Thenet Node TM-733A and 9600 baud packet (3 msgs) Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 13 Jun 94 08:07:56 EDT From: world!mv!lmr!rapp@uunet.uu.net Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu Erich Franz Stocker writes: ... stuff deleted ( Using Packet nodes for Internet nodes doesn't hold much appeal for me either, although, there's nothing wrong with saving money!) > While I can appreciate the BBS services of packet. I have to question > this as a main purpose in amateur radio. I'd like to see packet > turn into a more real time "communications" avenue. Logging into a > mail box isn't really radio. I disagree, Erich. I think it's as much a part of radio as contesting, dxing, experimenting - all those different modes. Frankly, it seems to me that traffic handling and bbs's are the thing for which packet is most suited. Voice communications seem to me to be far more efficient for real time. This based on holding a ticket for 40 years now and getting into just about everything I could. :) 73, Larry W1HJF ----------------------------------------------------------------------------- L. M. Rappaport & Associates, Inc. rapp@lmr.mv.com voice +1 603 237 8400 Colebrook, NH 03576-0158 CIS 72427,2567 fax +1 603 237 8430 ------------------------------ Date: 13 Jun 1994 12:58:32 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!gatech!concert!news-feed-1.peachnet.edu!news.duke.edu!godot.cc.duq.edu!codger!broderic@network.ucsd.edu Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu Chris Mcmahon (packman@cix.compulink.co.uk) wrote: : > I'm aware that TCP/IP is already available. But this is a suite of : > programs which operate only through packet, if I'm not mistaken. > : Ideally,any program which can run through standard TCP/IP should be able : > to run through a packet-radio version of TCP/IP. As far as I know, : this > is not currently the case. : I've made the same comment to some of the TCP/IP fanatics in this area. : They seem to be happy with the various flavours of NOS/NET that exist. : I'd like to add some 'features' to NOS, but I get put off by having to : try and figure out what the impact of my changes will be on the 350 (ish) : source code files that comprise JNOS (for example). What I'd ideally : like is a TCP/IP stack as a TSR that can have one or many hardware : drivers plugged into the bottom end and then present a standard API to : the programming world. Then standard telnet, etc could be used on top of : the TSR and I could write software using the API without having to worry : about messing up any of the underlying code. One possibility that could : be used, although I've not explored it, is some of the Winsock software. : Unfortunately that means learning to write sensible Windows programs :-( : I'm talking 'IBM PC world' here, but the same could easily apply to other : environments. ...... more deleted : Chris - G6FCI Packet : G6FCI @ GB7FCI.#16.GBR.EU : Internet : packman@cix.compulink.co.uk I was recently surprised to see references to ka9q code in a package of Ftp Software's PC/TCP for dos. This package comes with some winsock stuff (I think...), and although the source isn't available, one might coax an ax25 packet driver into working with it. I suspect that this is typical of many dos networking packages. As far as other computing environments, work done for Sunos, and recently Linux, points in this direction-- these provide kernel-layer interfaces to the ax.25 world. The chalenge now exists to write software to bridge between where packet users are today (mostly store/forward bbs style systems) to something a bit more transparent. Don Broderick N3GUZ ------------------------------ Date: Mon, 13 Jun 1994 15:06:26 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory!rsiatl!ke4zv!gary@network.ucsd.edu Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu In article rapp@lmr.mv.com (Larry Rappaport) writes: >Erich Franz Stocker writes: >> While I can appreciate the BBS services of packet. I have to question >> this as a main purpose in amateur radio. I'd like to see packet >> turn into a more real time "communications" avenue. Logging into a >> mail box isn't really radio. > >I disagree, Erich. I think it's as much a part of radio as contesting, >dxing, experimenting - all those different modes. Frankly, it seems to me >that traffic handling and bbs's are the thing for which packet is most >suited. Voice communications seem to me to be far more efficient for real >time. This based on holding a ticket for 40 years now and getting into just >about everything I could. :) I agree with Larry, realtime "chat" mode is about the worst use for packet. We have other modes that are much better suited to this type of use. Packet is useful for the things it can do better than other modes, and store and forward is a primary example of where packet is superior to other modes. Packet does that well, but it isn't a substitute for a microphone when the need is for realtime person to person communications. Hopefully, as the network speed increases, realtime machine to machine communications will become an important application facilitator, but right now non-realtime store and forward is the niche best served by packet. Gary -- Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv!gary Destructive Testing Systems | we break it. | uunet!rsiatl!ke4zv!gary 534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv!gary Lawrenceville, GA 30244 | | ------------------------------ Date: 13 Jun 1994 12:31:10 -0700 From: mdisea!not-for-mail@uunet.uu.net Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu In article , Larry Rappaport wrote: >suited. Voice communications seem to me to be far more efficient for real >time. Maybe from the standpoint of the user but not from the standpoint of channel usage. There's a reason the phone companies have gone digital /:) What we ought to have is packet voice! -=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hugh Shane | 206 487 5909 (PST) Motorola Wireless Data | N7UAX shane@mdd.comm.mot.com | #include -=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ------------------------------ Date: 13 Jun 1994 21:13:03 GMT From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!ssd.intel.com!chnews!cmoore@network.ucsd.edu Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu Hugh Shane (shane@mdd.comm.mot.com) wrote: : There's a reason the phone companies have gone digital : Hugh Shane | 206 487 5909 (PST) Hi Hugh, last time I checked, the initial deployment of IS-54 (digital) was no more bandwidth efficient than NAMPS (analog). And GSM (digital) is worse than NAMPS. 73, KG7BK, OOTC, CecilMoore@delphi.com ------------------------------ Date: 14 Jun 1994 00:36:33 GMT From: koriel!newsworthy.West.Sun.COM!abyss.West.Sun.COM!spot!myers@ames.arpa Subject: An open note to Gary Coffman, KE4ZV To: ham-digital@ucsd.edu In article 685@microsoft.com, davidar@microsoft.com (David Arnold) writes: >However, there are going to be some who will not want to dedicate a PC >to the problem. The problem can be solved in software, but the software >solution would only solve a particular platform configuration. >For example, if someone were to write a AX.25 NDIS driver, that would >solve the problem for a MS-DOS TCP/IP stack which support NDIS at the bottom, >which, BTW, is probably very common. Not a bad idea. In the System V world, an AX.25 Streams module would be cool, though a really good one would allow both AX.25 sessions and other networking sessions, and would be a multiplexor module, not as easy as a straight AX.25/IP module. NDIS should be pretty straightforward, though I have to write an NDIS driver. >Can you imagine running PC Mosiac for an Amateur Radio WWW? No. Well, on second thought, I can. It would suck. Here's a :-) for those who need it. --- * Dana H. Myers KK6JQ, DoD#: j | Views expressed here are * * (310) 348-6043 | mine and do not necessarily * * Dana.Myers@West.Sun.Com | reflect those of my employer * * This Extra supports the abolition of the 13 and 20 WPM tests * ------------------------------ Date: Mon, 13 Jun 1994 21:39:35 GMT From: microsoft!wingnut!davidar@uunet.uu.net Subject: Need info on Ottawa PI Card To: ham-digital@ucsd.edu Where can I get one, company contact names, etc. Thanks. davidar@microsoft.com KD6IFY ------------------------------ Date: 14 Jun 1994 02:15:46 GMT From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!news.bu.edu!dartvax.dartmouth.edu!usenet@network.ucsd.edu Subject: Packet Ideas Sought... To: ham-digital@ucsd.edu I'm thinking this summer about what I might want to do for a senior thesis in computer science next year, and I've decided that if it is possible, I would like to do something involving packet radio. Im still trying to think of something to do, however. I have a few thoughts: The focus of whatever I do is probably going to revolve around the nature of the amateur network as a fairly slow one (1200-9600 baud with rare exception.) It is also currently almost entirely accessed through text based terminal programs. There are a few specialty products on the market, but these are all most entirely specialty terminal programs. So, I could possibly explore something about the nature of the interface used to access the services in the network. I could possibly explore the use of something like an X Window system or similar open protocol for graphically-oriented distributed, client-server programs. Or I could possibly explore the netwrk for another angle, and ask the question "what services should be provided and how can they be best provided?" "What sort of changes/enhancements in the network will be the most beneficial to the user community?" Is there something like hypertext that will greatly improve the nature of the network? If you have any thoughts on this, I would appreciate it if you would drop me a line, or start up a general discussion of it here. I'm just sort of collecting thoughts at this stage, so anything might help. Also, if anyone knows of a good source for technical documentation on AX.25 or TCP/IP or the packet network in general, I would appreciate the pointers. Thanks and 73's... --- ======================================================================= Kenneth E. Harker N1PVB Dartmouth College Amateur Packet Radio kenneth.e.harker@dartmouth.edu Hinman Box 1262 n1pvb@w1et.nh.usa.na (603) 643-5716 Hanover, NH 03755 or n1pvb-5 on 144.99 ======================================================================= (PGP Public Key now available on request) ------------------------------ Date: 14 Jun 1994 08:55:09 GMT From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!xlink.net!scsing.switch.ch!swidir.switch.ch!univ-lyon1.fr!lanpc1.univ-lyon1.fr!cerdini@network.ucsd.edu Subject: Thenet Eprom 1X for Thenet Node To: ham-digital@ucsd.edu I'm looking for contents of Thenet Eprom 1X for Thenet Node (data which are loaded in TNC eprom)... Someone know where I can found that ? -- Michel CERDINI - Universite Lyon 1 | E-Mail cerdini@lan1.univ-lyon1.fr Laboratoire d'Analyse Numerique URA 740 | Tel Pro 72 43 10 93 - aka Djoe 43, boul. du 11 novembre 1918 | Minitel 78 36 19 96 (24h/24) v 69622 Villeurbanne Cedex, France. | Modem 78 36 10 01 (V-Fast) _/ ------------------------------ Date: 13 Jun 1994 15:29:04 GMT From: ihnp4.ucsd.edu!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@network.ucsd.edu Subject: TM-733A and 9600 baud packet To: ham-digital@ucsd.edu I have a TM-733A and I would like to talk with others who are currently using it for 9600 baud packet... I would like to know what TXdelay you are running. I seem to have to keep TXDelay at 18... Which seems long. Other than that... It seems to work perfectly! Phil de kj6nn ------------------------------ Date: 13 Jun 1994 16:08:50 GMT From: news.larc.nasa.gov!arbd0.larc.nasa.gov!zawodny@ames.arpa Subject: TM-733A and 9600 baud packet To: ham-digital@ucsd.edu In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes: >I have a TM-733A and I would like to talk with others who are currently using >it for 9600 baud packet... > >I would like to know what TXdelay you are running. I seem to have to keep >TXDelay at 18... Which seems long. Other than that... It seems to work >perfectly! > Wow! I'd love to be able to set my TXDelay at 18 (180ms). I currently have to set it to 40 with my GE Custom MVP. Anyone got any ideas how I can speed my MVP up? How about mods for 9600 buad? -- Joseph M. Zawodny (KO4LW) NASA Langley Research Center Internet: zawodny@arbd0.larc.nasa.gov MS-475, Hampton VA, 23681-0001 Packet: ko4lw@n4hog.va.usa ------------------------------ Date: 13 Jun 1994 20:59:15 GMT From: usc!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com!hansen.ncd.com!phil@ihnp4.ucsd.edu Subject: TM-733A and 9600 baud packet To: ham-digital@ucsd.edu I thought that most 9600 baud folks were trying to run with a TX delay of 7 to 9 (aka 70 to 80 ms)... How about it... What is common for 9600 baud? phil de kj6nn In article <2ti0ai$f9p@reznor.larc.nasa.gov>, zawodny@arbd0.larc.nasa.gov (Joseph M Zawodny) writes: |> In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) writes: |> >I have a TM-733A and I would like to talk with others who are currently using |> >it for 9600 baud packet... |> > |> >I would like to know what TXdelay you are running. I seem to have to keep |> >TXDelay at 18... Which seems long. Other than that... It seems to work |> >perfectly! |> > |> |> Wow! I'd love to be able to set my TXDelay at 18 (180ms). I currently have to |> set it to 40 with my GE Custom MVP. Anyone got any ideas how I can speed my |> MVP up? How about mods for 9600 buad? ------------------------------ Date: Mon, 13 Jun 1994 15:09:52 GMT From: world!dts@uunet.uu.net To: ham-digital@ucsd.edu References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, dts Subject : Re: info wanted: new Kantronics 9k6 modem In article wb6w@netcom.com (Glenn Thomas) writes: >Gary Coffman (gary@ke4zv.atl.ga.us) wrote: >: In article <2tf0kb$rql@eldborg.rhi.hi.is> bnt@rhi.hi.is (Benedikt Sveinsson) writes: >: >Hello. >: >I was just hearing about the new Kantronics 9k6 packet >: >modem. I saw the advertisment in QST, but no price or >: >free the MFJ from the packet only operation on my BBS. > >: The Kantronics 9600 baud modem is a G3RUH copy, like the MFJ >: and the PacComm. The only difference is in form factor of the >: card to fit the different TNCs. Street price is in the range >: of $87-$109 at most shows. Aside from kludging the packaging, >: your MFJ 9600 baud modem will work in the KAM. > >: Gary > >Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep >about the KAM and 9600 and was told that the KAM does its HDLC processing in >software rather than the hardware implementation that the TAPR II and clones >use. The software is fine for 1200 baud and slower, but just can't handle >9600. The Kantronics data engine does work very well at 9600 and a G3RUH >clone ought to work well in an TNC II clone. > >Oh...I understand that the KPC-3 also does HDLC in software, so it will never >do 9600 either. Kantronics has just announced a new box that handles one port for 9600 packet and another for 1200 packet. The HDLC framing is in software. Keep in mind that there is absolutely nothing wrong with using a software solution. It allows a MUCH simpler method for providing fixes should a problem be found. Suppose you find a bug in an HDLC-capable SCC chip? The usual answer to that is to live with it... I'm looking forward to trying one of the new Kantronics 9600 boxes... Dan N1JEB -- --------------------------------------------------------------- Daniel Senie Internet: dts@world.std.com Daniel Senie Consulting n1jeb@world.std.com 508-779-0439 Compuserve: 74176,1347 ------------------------------ Date: Mon, 13 Jun 1994 12:43:59 GMT From: ihnp4.ucsd.edu!swrinde!emory!rsiatl!ke4zv!gary@network.ucsd.edu To: ham-digital@ucsd.edu References <2tf0kb$rql@eldborg.rhi.hi.is>, <1994Jun12.140915.1245@ke4zv.atl.ga.us>, Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman) Subject : Re: info wanted: new Kantronics 9k6 modem In article wb6w@netcom.com (Glenn Thomas) writes: > >Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep >about the KAM and 9600 and was told that the KAM does its HDLC processing in >software rather than the hardware implementation that the TAPR II and clones >use. The software is fine for 1200 baud and slower, but just can't handle >9600. The Kantronics data engine does work very well at 9600 and a G3RUH >clone ought to work well in an TNC II clone. > >Oh...I understand that the KPC-3 also does HDLC in software, so it will never >do 9600 either. Hmm. Good point Glenn. I used real TNC2 type TNCs when I was using TNCs. I had forgotten that the Kantronics boxes are gutless wonders. Still, I do know that the Kantronics 9600 baud modem that fits the Data Engine (and the Gracillis PacketTwin) is a G3RUH clone, and will work with MFJ and PacComm TNCs, though it's physically the wrong shape to fit in the cases. Gary -- Gary Coffman KE4ZV | You make it, | gatech!wa4mei!ke4zv!gary Destructive Testing Systems | we break it. | uunet!rsiatl!ke4zv!gary 534 Shannon Way | Guaranteed! | emory!kd4nc!ke4zv!gary Lawrenceville, GA 30244 | | ------------------------------ End of Ham-Digital Digest V94 #194 ******************************